-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature(split): add support for sensors from peripheral #1841
feature(split): add support for sensors from peripheral #1841
Conversation
0612d49
to
0da2c45
Compare
working fine on Hillside 52 |
Should we update the docs in this PR or do it in another one after merging? Places to update:
|
Good catch. Updated here in a new commit. |
This comment was marked as resolved.
This comment was marked as resolved.
Working on sofle v2! Thanks for this amazing job. I hope it arrives to master :) |
I tested on my keyboard and there is one big issue: whenever I on a layer the keyboard registers both mappings: both for the current layer and for the default layer. Upd: after flashing the build from the CI it works perfectly fine. Something is wrong in my local tooling. |
585c7f6
to
fb19a3f
Compare
Tested on SofleV2.1 with nano v2 wired (I don't have any batteries yet). Everything works. Both encoders are working. |
Fixed, with some help from Mike on Discord. |
Just tested it and can confirm this is working with Waterfowl after cherry-picking my config update from DiogoDoreto@fb7c374 Thanks for your work! |
Tested on Splitkb Aurora Lily58 and it works, thank you! |
Works on my custom split keyboard flawlessly. |
I'm curious to know what is this pr blocked on? Does it need a review? |
Yes, the main thing remaining is review, which will happen when others on the team have bandwidth to do so. |
fb19a3f
to
72ca2fa
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can report that this PR at least partially fixes a bug introduced in 295ed83, after which encoder events in this config began triggering too often.
I still get 4 calls to volume up or down per-step if the configuration uses resolution
(as this shield unfortunately still does in main
), but switching to steps
/triggers-per-rotation
works as expected.
I currently have no way to test the split part of this.
e: After another look this morning, applying the changes in 72ca2fa alone seems to have solved the problem. I am not sure if extracting that commit from the feature PR will break anything. Will have to see if I can rope anyone with a fully-assembled keyboard into testing the bugfix.
Per lesshonor's roping I tested this on a fully assembled Pillbug Waka. It fixed the issues I was experiencing: every third encoder detent would not send a code and the encoder would not work on layers. |
Also as per Lesshonor, this PR was tested on a Pillbug with bb40 shield. Encoder performance was showing 2-5 activations per detent; after reflashing with this PR, I am getting the expected 1 activation per detent (1 in 15 seem to be missed, but that could be hardware) using Steps and Trigger. Split functionality was not tested. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks pretty good to me, except I think we should have better error checking when reading data into the sensor_event structs.
int zmk_split_bt_position_released(uint8_t position); | ||
int zmk_split_bt_sensor_triggered(uint8_t sensor_number, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: sensor_event
uses sensor_index
, while this uses sensor_number
. Are these the same thing? If so, making the name consistent would be good.
This also appears to be all the same data as a sensor_event
. Could you just pass a pointer to that struct instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So.... struct sensor_event
was intended as a data exchange format, which is why it is packed. I'm hesitant to have a data exchange struct also be used for public API like this. Thoughts?
LOG_DBG("[SENSOR NOTIFICATION] data %p length %u", data, length); | ||
|
||
struct sensor_event sensor_event; | ||
memcpy(&sensor_event, data, MIN(length, sizeof(sensor_event))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be a good idea to verify that length >= offsetof(struct sensor_event, channel_data)
. Otherwise, it would be possible to not write anything to channel_data_size
, and then the array size will be a garbage value which may cause other code to read past the end of the array.
Also, we are truncating the array data if given more channels than we support, but we aren't clamping channel_data_size
accordingly. This means we're protecting against writing past the end of the array, but not reading past it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added a check there.
This commit adds a new GATT characteristics on the peripheral side and wires it up to read sensor values. The central side subscribes to this new characteristics and replays sensor values on its side. Co-authored-by: Peter Johanson <[email protected]>
* Don't accept data for the same behavior on multiple layers more than once, to avoid duplicate/extraneous triggers.
72ca2fa
to
1672524
Compare
This commit adds a new GATT characteristics on the peripheral side and wires it up to read sensor values. The central side subscribes to this new characteristics and replays sensor values on its side.
This is building off the awesome work in #728 but updated to leverage the sensor refactors recently merged in #1039